#Kopf !tex !tex !tex !tex

!tex cmss

!tex =graphic

!stg @subject "Dokumentation/Utilities" !stg @options +zz

!author Steffen Engel !street Kr�ppelstr. 2 !town D-38100 Braunschweig !email MausNet: Steffen Engel @ SZ2

!title Systemglobaler SCSI-Treiber !program SCSIDRV !version Release 1.00 #!date Date : 1995/11/2310 : 37 : 26

#!rtf_no_quotes !rtf_propfont Dutch !rtf_monofont Typewriter

!tex_lindner !tex_dpi 100

#!asc_no_effects

# Die Silbenregeln !include hyphens.ui

!begin_document

!maketitle !tableofcontents

#**************************************************************************** # # Source : f : .ii.u, v # # Revision : 1.4 # # Author : S_Engel # # Date : 1995/11/2310 : 37 : 26 # # State : Exp # #**************************************************************************** # History: # # Revision 1.3 1995/09/29 08:06:18 S_Engel # Verhalten unter virtuellem RAM dokumentiert. # # Revision 1.2 1995/02/10 00:52:50 S_Engel # Handlekonzept eingef�hrt, Doku erweitert # # Revision 1.1 1995/02/05 10:40:00 S_Engel # Initial revision # #****************************************************************************

!node Vorwort

Diese Dokumentation ist nicht kurz, sie ist aber wichtig. Ich empfehle, den Text auszudrucken, da er dann wesentlich �bersichtlicher ist.

Wesentlich ist der Teil zum Absetzen von SCSI-Kommandos und zur Abfrage der vorhandenen Busse. Der Teil zur Installation von Targetroutinen ist nur f�r spezielle F�lle n�tig. Die dazugeh�rigen Funktionen m�ssen vom Treiber auch nicht bereitgestellt werden. Die Existenz der Strukturen und des Treibers lassen also keine R�ckschl�sse auf die M�glichkeit zur Installation von Target-Routinen oder Disconnect zu.

Wer einen Treiber benutzen oder selbst schreiben m�chte, hier sind besonders die Autoren von Festplattentreibern gefragt, sollte als erstes die Funktionen zur Benutzung und Abfrage der SCSI-Schnittstellen beachten. Eine eventuelle Unterst�tzung der Target-Routinen kann sp�ter folgen.

Als Beispiele kann man sich die beiligenden Programme und Quelltexte ansehen.

!node Einleitung

F�r den Atari fehlen seit jeher systemglobale SCSI-Routinen. Dummerweise mu� daher jeder, der SCSI-Ger�te programmieren will, eigene SCSI-Routinen schreiben, was mit jedem neuen Rechner von vorne los geht.

Desweiteren ist es sinnvoll, mit den echten SCSI-Ports (wie bei TT, Falcon oder der Medusa) auch als Target auftreten zu k�nnen.

Dazu kommen alternative SCSI-Ports, wie sie durch Zusatzkarten in ST, TT oder der Medusa eingesetzt werden.

Besonders wichtig sind Emulatoren (zB MagiCMac, STonX) oder alternative Rechner (Clones), an deren SCSI-Ports man ja nicht herankommt, wenn man die Hardware nicht kennt.

Daher dieser Entwurf zur Installation eines globalen SCSI-Handlers. Potentiell kann der Handler bereits im Betriebssystem installiert werden, womit Plattentreiber auch auf die alternativen SCSI-Ports zugreifen k�nnen, ohne Kenntnis von der Implementierung der Hardware zu haben.

Daraus ergibt sich die folgende Vorgehensweise f�r alle SCSI nutzenden Programme:

!begin_itemize !item Bei Existenz des SCSI-Cookies sollen die darin zur Verf�gung gestellten Funktionen verwendet werden. !item Existiert der Cookie nicht, sollten, soweit vorhanden, eigene Routinen verwendet werden.

Bei Programmen, die nur auf den hier verwendeten Routinen aufsetzen und keine eigenen Routinen on board haben, mu� dementsprechend mit einer Fehlermeldung abgebrochen werden. !end_itemize

Auch Plattentreiber sollten dies so machen, denn es k�nnen SCSI-Treiber rersetfest oder im ROM eingebunden werden, die dann vom Plattentreiber benutzt werden sollten.

Sollte der Cookie nicht installiert sein, so ist es sinnvoll, wenn Plattentreiber diesen installieren, um ihre eigenen Routinen global zur Verf�gung zu stellen.

Erw�nschter Leistungsumfang des SCSI-Treibers: !begin_itemize !item F�higkeit zu krummen Transferzahlen auf ACSI (Stichwort DMA-fifo-Loch) !item Class 1 Komandos auf ACSI (per ALIA-Technik, Linked-Cmd oder ICD-Technik) !item FRB-Transfers (ACSI) sind Aufgabe des Treibers !end_itemize

!subnode Strukturen

!begin_verbatim XBRA : SCSI

Vektoren : Falcon : MFP-Interrupt 7, Vektor 7 (normal VR 40 - >11C) TT : TT-MFP-Interrupt 15, Vektor 7 (normal VR 50 - >17C) !end_verbatim

Aufbau des SCSI-Cookies:

Name des Cookie: SCSI Wert des Cookie: Zeiger auf die Struktur tScsiCall (Typen siehe SCSIDEFS.H, SCSIDEFS.D)

!subnode Nomenklatur

!begin_xlist [BOOLEAN: ] !item [BYTE:] 8 Bit (unsigned char) !item [UWORD:] 16 Bit ganzzahlig positiv (unsigned word) !item [ULONG:] 32 Bit ganzzahlig positiv (unsigned long) !item [WORD:] 16 Bit ganzzahlig (word) !item [LONG:] 32 Bit ganzzahlig (long) !item [BOOLEAN:] WORD TRUE : 1 FALSE : 0 !end_xlist

benutzte Register in den Routinen: D0-D2, A0-A1 (PureC-Konvention)

Parameter�bergabe: auf dem Stack (cdecl) ( NEIN!! nichts anderes!!! )

!node Funktionen

!subtoc [stg,html,pch]

!subnode In

Sendet ein SCSI-Kommando und empf�ngt die kommenden Daten.

Als Parameter wird ein Zeiger auf eine SCSI-Kommandostruktur �bergeben, in der alle n�tigen Informationen �ber den gew�nschten Zugriff enthalten sind.

!begin_verbatim LONG cdecl (*In) (tpSCSICmd Parms);

typedef struct tHandle Handle; /* Handle f�r Bus und Ger�t */ BYTE *Cmd; /* Zeiger auf CmdBlock */ UWORD CmdLen; /* L�nge des Cmd-Block void *Buffer; /* Datenpuffer */ ULONG TransferLen; /* �bertragungsl�nge */ BYTE *SenseBuffer; /* Puffer f�r ReqSense (18 Bytes) */ ULONG Timeout; /* Timeout in 1/200 sec */ UWORD Flags; /* Bitvektor f�r Ablaufw�nsche */ #define Disconnect 0x10 /* versuche disconnect */

tSCSICmd; typedef tSCSICmd *tpSCSICmd; !end_verbatim

!begin_xlist [SenseBuffer: ] !item [Handle:] Das Handle des angesprochenen Ger�tes !item [Cmd:] Zeiger auf den zu �bertragenden Kommandoblock. !item [CmdLen:] L�nge des Kommandoblockes (!N)Die Kommandol�nge ist eigentlich f�r einen SCSI-Treiber nicht n�tig. Da ACSI jedoch nicht targetgesteuert ablaufen kann, einige Plattentreiber dieses Feature auch auf den echten SCSI-Ports nicht verwenden und zuk�nftige Ger�tetreiber f�r Clones (Mac/Gemulator/STOnX) evtl. diesen Wert ebenfalls ben�tigen, mu� er immer angegeben werden.(!n) !item [Buffer:] Zeiger auf den Transferpuffer !item [TransferLen:] Anzahl der zu �bertragenden Bytes. !item [SenseBuffer:] Puffer f�r Request Sense Daten.

Wird automatisch gef�llt, wenn das Ger�t Check Condition meldet. !item [Timeout:] Maximale Wartezeit f�r die Ausf�hrung des Kommandos in 1/200 sec. !item [Flags:] Bitvektor mit Zusatzinformationen/aufforderungen !end_xlist

Bemerkung: die L�nge des Kommandoblockes ist eigentlich nur f�r ACSI n�tig, oder f�r Treiber, die nicht vom Target gesteuert werden. Daher mu� sie immer korrekt �bergeben werden (!N) Laut SCSI-Norm steuert das angesprochene Target die Bus-Phasen. Das hei�t, das Target fordert solange Kommando-Bytes an, bis es die Anzahl der zu dem Kommando geh�renden Bytes erhalten hat.

Daher ist es f�r die SCSI-Routinen nicht n�tig, zu wissen, wie lang das Kommando ist.

Bei ACSI kann die Busphase nicht abgefragt werden, daher mu� die Kommandol�nge immer genannt werden. (!n)

Ergebnis: !begin_verbatim NOSCSIERROR 0L /* Kein Fehler */ SELECTERROR -1L /* Fehler beim Selektieren */ STATUSERROR -2L /* Default-Fehler */ PHASEERROR -3L /* ung�ltige Phase */ BSYERROR -4L /* BSY verloren */ BUSERROR -5L /* Busfehler bei DMA-�bertragung */ TRANSERROR -6L /* Fehler beim DMA-Transfer (nichts �bertragen) */ FREEERROR -7L /* Bus wird nicht mehr freigegeben */ TIMEOUTERROR -8L /* Timeout */ DATATOOLONG -9L /* Daten f�r ACSI-Softtransfer zu lang */ LINKERROR -10L /* Fehler beim Senden des Linked-Command (ACSI) */ TIMEOUTARBIT -11L /* Timeout bei der Arbitrierung */ PENDINGERROR -12L /* auf diesem handle ist ein Fehler vermerkt */ PARITIYERROR -13L /* Transfer verursachte Parity-Fehler */

Wert gr��er Null: Statusbyte des SCSI-Ger�tes, bei Status 2 (Check Condition) befinden sich die RequestSense-Daten im Sensebuffer.

!end_verbatim

BEISPIEL:

Aufruf von Inquiry

!begin_verbatim WORD Inquiry(tHandle handle, char *inqdata) tScsiCmd ScsiCmd; BYTE CmdBlock[6]=0x12,0,0,0,36,0; /* Kommand 18, 36 Bytes */ BYTE ReqBuff[18];

ScsiCmd.Handle = handle; /* Ger�tehandle */ ScsiCmd.Cmd = CmdBlock; /* das Kommando */ ScsiCmd.CmdLen = 6; /* 6-Byte-Kommando */ ScsiCmd.Buffer = inqdata; /* Datenpuffer */ ScsiCmd.TransLen = 36; /* 36 Bytes erwartet */ ScsiCmd.SenseBuffer = ReqBuff; /* bei Fehlern dorthin */ ScsiCmd.Timeout = 1000; /* 5 sec */ ScsiCmd.Flags = 0; /* keine Besonderheiten */ return (ScsiCall->In((tpScsiCmd)&ScsiCmd)); !end_verbatim

ACHTUNG: Bei virtuellem RAM ist selbst auf den Transfer �ber ST-RAM zu achten (s. Abschnitt VIRTUELLES RAM)

!subnode Out

Sendet ein SCSI-Kommando und sendet die Daten. Parameter wie bei In.

!begin_verbatim LONG cdecl (*Out) (tpSCSICmd Parms);

typedef struct tHandle Handle; /* Handle f�r Bus und Ger�t */ BYTE *Cmd; /* Zeiger auf CmdBlock */ UWORD CmdLen; /* L�nge des Cmd-Block (f�r ACSI n�tig) */ void *Buffer; /* Datenpuffer */ ULONG TransferLen; /* �bertragungsl�nge */ BYTE *SenseBuffer; /* Puffer f�r ReqSense (18 Bytes) */ ULONG Timeout; /* Timeout in 1/200 sec */ UWORD Flags; /* Bitvektor f�r Ablaufw�nsche */ #define Disconnect 0x10 /* versuche disconnect */

tSCSICmd; typedef tSCSICmd *tpSCSICmd; !end_verbatim

ACHTUNG: !begin_verbatim Bei virtuellem RAM ist selbst auf den Transfer �ber ST-RAM zu achten (s. Abschnitt VIRTUELLES RAM) !end_verbatim

!subnode InquireSCSI

!begin_verbatim LONG cdecl (*InquireSCSI) (WORD what, tBusInfo *Info); #define cInqFirst 0 #define cInqNext 1

typedef struct tPrivate Private; /* f�r den Treiber */ char BusName[20]; /* zB 'SCSI', 'ACSI', 'PAK-SCSI' */ UWORD BusNo; /* Nummer, unter der der Bus anzusprechen ist */ UWORD Features; #define cArbit 0x01 /* auf dem Bus wird arbitriert */ #define cAllCmds 0x02 /* hier k�nnen ale SCSI-Cmds abgesetzt werden */ #define cTargCtrl 0x04 /* Das Target steuert den Ablauf (so soll's sein!) */ #define cTarget 0x08 /* auf diesem Bus kann man sich als Target installieren */ #define cCanDisconnect 0x10 /* Disconnect ist m�glich */ #define cScatterGather 0x20 /* scatter gather bei virtuellem RAM m�glich */ /* bis zu 16 Features, die der Bus kann, zB Arbit, * Full-SCSI (alle SCSI-Cmds im Gegensatz zu ACSI) * Target oder Initiator gesteuert * kann alle Adressen bedienen (Stichwort: ACSI-Port im TT!) * Ein SCSI-Handle ist auch ein Zeiger auf eine Kopie dieser Information! */ ULONG MaxLen; /* maximale Transferl�nge auf diesem Bus (in Bytes) * entspricht zB bei ACSI der Gr��e des FRB * minimal 64kB (eine FRB-Gr��e) */ tBusInfo; !end_verbatim

Nach vorhandenen Bussen suchen. Man ruft, �hnlich zu Fsfirst/Fsnext, zun�chst mit InqFirst in what auf, danach mit InqNext, bis ein negativer Wert auftritt. Die Reihenfolge der Meldungen (erst Bus 0, dann 1 dann 2) ist _nicht_ gew�hrleistet, es kann auch sein, da� erst Bus 3, dann Bus 2, dann 0, dann 1 gemeldet wird.

Es sind maximal 32 Busse m�glich.

Man erh�lt Informationen �ber den Bus in der Info-Struktur.

Ergebnis:

!begin_verbatim = 0 : Ok < 0 : Kein weiteres Ger�t !end_verbatim

ACHTUNG: es mu� nat�rlich immer der gleiche Record f�r Info genommen werden, da darin vom Treiber protokolliert wird, welche bereits gemeldet wurden.

Aufgabe: F�r Konfigurationsdialoge oder auch selbstt�tige Konfiguration nach den vorhandenen Bussen suchen.

Dabei sind vorbelegt die Bus-Nummern 0 (ACSI), 1 (Standard-SCSI: Falcon, TT, Medusa, MagicMac...) und 2 (IDE in Atari-kompatiblen)

Es sind dennoch keine Annahmen �ber die Anzahl der Ger�te oder die maximale Ger�te-Id zul�ssig. Die vorhandenen Ger�te m�ssen mit InquireBus erfragt werden.

Beispiel: siehe SRCHDRV.C

!subnode InquireBus

!begin_verbatim LONG cdecl (*InquireBus) (WORD what, WORD BusNo, tDevInfo *Dev);

typedef struct BYTE Private[32]; DLONG SCSIId; tDevInfo;

!end_verbatim

Einen Bus nach vorhandenen Ger�ten abfragen. Erster Aufruf mit cInqFirst, danach mit cInqNext. Liefert 0, bis keine weiteren Ids mehr berichtet werden.

Ergbenis: !begin_verbatim = 0 : Ok < 0 : keine weiteren Ger�te !end_verbatim

Beispiel: siehe SRCHDRV.C

!subnode CheckDev

!begin_verbatim LONG cdecl (*CheckDev) (WORD BusNo, const DLONG *SCSIId, char *Name, UWORD *Features); !end_verbatim

Wie InquireSCSI, nur da� explizit nach einem bestimmten Bus und einer bestimmten SCSI-ID gefragt wird.

Als Antwort erh�lt man den Namen des Busses, sowie die Informationen, was mit dem genannten Ger�t m�glich ist.

Ergebnis: !begin_verbatim = 0 : Ok < 0 : Fehler -2 EDRIVNR : Informationen konnten nicht ermittelt werden (zB Kontrolle auf ICD-F�higkeit) -15 EUNDEV : Die Busnummer oder die Ger�tenummer wird nicht verwaltet -36 EACCDN : Zugriff nicht m�glich (zB eigene SCSI-Id auf einem arbitrierenden Bus) !end_verbatim

Dies ist f�r zwei Dinge sinnvoll:

!begin_itemize !item Ein Programm l�dt eine Parameterdatei und kann hiermit kontrollieren ob !begin_itemize !item der Bus existiert !item der Busname ver�ndert ist (bei alternativen Bussen k�nnen Unterschiede vorhanden sein) !item das Ger�t ansprechbar ist !end_itemize

!item F�r alternative Hostadapter kontrolliert der Treiber, ob er speziell dieses Ger�t anders ansprechen kann, als auf dem Bus �blich (zB ICD: voller Kommandosatz auf ACSI auf _diesem_ Ger�t) !end_itemize

!subnode RescanBus

!begin_verbatim LONG cdecl RescanBus (WORD BusNo); !end_verbatim

Der Bus soll vom Treiber erneut auf vorhanden Ger�te kontrolliert werden.

F�r Applikationen zwei sinnvolle Anwendungen: !begin_enumerate !item Tool f�r Kontrolle auf nachtr�glich eingeschaltete Ger�te. Beispiel: SCSI.CPX !item Programm sucht nach einem bestimmten Ger�t und findet es nicht. Einmal RescanBus, danach neue Suche. Beispiel: GEMAR. Wenn kein Streamer gefunden wurde, wird nach einem RescanBus noch mal nach einem Streamer geschaut. !end_enumerate

Dadurch k�nnen nachtr�glich eingeschaltete Ger�te in der Ger�teliste aufgenommen werden.

!subnode Open

!begin_verbatim LONG cdecl (*Open) (WORD BusNo, const DLONG *SCSIId, ULONG *MaxLen); !end_verbatim

Ein Handle f�r ein Ger�t holen.

SCSIId ist die SCSI-Id des Ger�tes, f�r das das Handle geliefert werden soll. Die Variable ist 64 Bit gro�, um die Vorgaben von SCSI-3 erf�llen zu k�nnen. Bei den bisher zur Verf�gung stehenden Treibern und Bussen werden nur die unteren 8 Bit (von SCSIId.lo) verwendet. Der Rest mu� 0 sein. Es ist nicht zul�ssig, irgendwelche anderen Informationen in der SCSI-Id unterzubringen!

Ergebnis !begin_verbatim > 0 : handle (Zeiger auf Featurevektor) In MaxLen ist angegeben, welche maximale Transferl�nge mit einem Zugriff �bertragen werden kann. < 0 : Fehler ENMHDL : keine Handles mehr frei EUNDEV : unbekanntes Ger�t auf diesen Bus/unbekannter Bus EACCDN : unerlaubtes Ger�t auf diesem Bus (zB eigene SCSI-Id bei Arbitrierung) !end_verbatim

!subnode Close

!begin_verbatim LONG cdecl (*Close) (tHandle handle); !end_verbatim

Handle wieder freigeben

Ergebnis: !begin_verbatim = 0 : Ok < 0 : Fehler EINVHDL : ung�ltiges Handle !end_verbatim

!subnode Error

!begin_verbatim LONG cdecl (*Error) (tHandle handle, WORD rwflag, WORD ErrNo); #define cErrRead 0 #define cErrWrite 1 #define cErrMediach 0 #define cErrReset 1 !end_verbatim

Fehlerstatus auf dem Ger�t abfragen/setzen

Hiermit kann man fragen, welche Fehler auf dem Ger�t in letzter Zeit aufgetreten sind. Dies ist n�tig, da evtl. mehrere Programme mit diesem Ger�t arbeiten und damit derjenige, der den Status mit Request Sense ausliest, der einzige ist, der wei�, was passiert ist. Daher mu� jeder, der Request Sense auswertet, einen entsprechenden Fehler melden, damit dieser f�r alle anderen Prozesse mit einem offenen Hande protokolliert wird.

Gemeldet werden mu� alles, was einen Wechselstatus des Ger�tes ergibt, also Mediach und Reset. Nur so kann zB der Plattentreiber einen Mediachange mitbekommen, wenn bei einem Image-Backup das Medium gewechselt wurde.

rwflag = 0 fragt den Status ab (16 Bit Bitvektor) und l�scht ihn f�r dieses handle. rwflag = 1 setzt das Bit ErrNo bei allen auf dieses Ger�t ge�ffneten handles.

!subnode Install Nur f�r Targethandling, siehe SCSIDRV2

!subnode Deinstall Nur f�r Targethandling, siehe SCSIDRV2

!subnode GetCmd Nur f�r Targethandling, siehe SCSIDRV2

!subnode SendData Nur f�r Targethandling, siehe SCSIDRV2

!subnode GetData Nur f�r Targethandling, siehe SCSIDRV2

!subnode SendStatus Nur f�r Targethandling, siehe SCSIDRV2

!subnode SendMsg Nur f�r Targethandling, siehe SCSIDRV2

!subnode GetMsg Nur f�r Targethandling, siehe SCSIDRV2

!subnode ReqData Nur f�r Targethandling, siehe SCSIDRV2

!node Virtuelles RAM

Bei vorhandenem virtuellem RAM ist es dem Treiber leider nicht m�glich, selbstt�tig die physikalische Adresse des zu transferierenden Speichers zu ermitteln (die virtuellen Treiber liefern keinerlei solche Information). Eine eigenst�ndige Entscheidung des Treibers, wann die Daten durch einen Puffer im ST-RAM zu kopieren sind, erscheint auch nicht sinnvoll, da zur Vermeidung von Deadlocks f�r jeden Proze� ein eigener Puffer eingerichtet werden m��te. Daher m�ssen Programme selbstt�tig davor sorgen, da� der zu transferierende Speicher im ST-RAM liegt, wenn virtuelles RAM vorliegt (siehe auch SCSILIB.H). Der Transfer f�r ACSI-Zugriffe �ber den FRB bzw den XFRB stellt dabei kein Problem da.

!node Tips

Wenn ein Programm den Treiber benutzt, sollte es unbedingt auf ein Ger�t ein InquireDev absetzen. Dies ist sinnvoll, wenn der Treiber dadurch feststellen kann, was f�r ein Adaptertyp zB auf ACSI liegt. Meine Routinen checken dabei, ob es sich um einen ALIA handelt, oder auch um einen ICD-Adapter. Im Falle eines ICD-Adapters ergibt sich dadurch die M�glichkeit, da� der Treiber f�r Class-1-Kommandos die ICD-Technik benutzt.

!node Treiberinstallation

Dieses Kapitel ist noch nicht fertiggestellt.

Es werden nur wesentliche Stichpunkte genannt, die von Treibern zu beachten sind.

Wenn bereits ein Treiber installiert ist:

!begin_itemize !item Treiber d�rfen bereits existierende Busse nicht ersetzen, es mu� also zun�chst nach Bussen gescannt werden, dann k�nnen die eigenen Busse auf freie Bus-Ids gelegt werden.

Der Cookieinhalt des vorhergehenden Treibers wird dann gemerkt und die eigenen Daten werden in die Struktur des alten Treibers geschrieben, die Daten werden also ersetzt.

Der Cookiewert (der Zeiger im Cookiejar) darf NICHT ersetzt werden.

!item Tabellen und Variablen m�ssen beim Treiberstart initialisiert werden. Initialisierte Varibalen (DATA-Segement) sind nicht zul�ssig, da ein resetfest geladener Treiber (Stichwort SCSI.RAM bei MagiC) dann nicht funktionieren kann.

!item die Fehlermeldungen die ein Treiber zu melden hat/melden kann:

!begin_description !item[NOSCSIERROR] Alles klar, kein Fehler !item[SELECTERROR] Das Ger�t konnte nicht selektiert werden. Bei SCSI ein Timeout auf /SEL (/BSY kam nicht) !item[STATUSERROR] Defaultfehler, wenn gar nix geht !item[PHASEERROR] Eine ung�ltige Phase wurde erkannt. Diese Fehlermeldung ist f�r Busphasen vorgesehen, die nicht der SCSI-Norm entsprechen. Dies sind die Phasen mit /C/D = 0, /MSG = 1 und /I/O = 0 oder = 1 !item[BSYERROR] Das Target hat unkontrolliert den Bus freigegeben (busy loss) !item[BUSERROR] Busfehler bei der �bertragung (zB die Fehlermeldung des TT-DMA-Chip) !item[TRANSERROR] Beim DMA-Transfer keine Daten �bertragen. Nur verwenden, wenn Datenphase eingeleitet, aber dann nichts �bertragen wurde, also als Ger�tefehler, nicht als SCSI-Fehler zu verstehen. !item[FREEERROR] Wenn der Bus nach Abschlu� (Msg Complete) nicht freigegeben werden konnte (Busy bleibt stehen) !item[TIMEOUTERROR] Ein Timeout bei der Verbindung (nicht Selektion, dort SELECTERROR verwenden) !item[DATATOOLONG] So viele Daten k�nnen nicht mit einem Transfer �bertragen werden (zB FRB-Gr��e). !item[LINKERROR] Bei Linked-Cmd trat Fehler auf (spezielle Meldung f�r ACSI mit Linked Cmds !item[TIMEOUTARBIT] Wenn innerhalb einer vom Treiber vorzusehenden Zeit keine Arbitrierung um den Bus mit Erfolg beendet werden konnte. !item[PENDINGERROR] Soll gemeldet werden, wenn auf einem handle noch ein Fehler gemerkt und nicht abgeholt ist. Der Klient mu� mit Error(cErrRead) den Fehler abholen, dann wird der Fehler auf diesem Handle gel�scht. !item[PARITYERROR] es ist ein Parityfehler aufgetreten !end_description

!end_itemize ;''